In service-oriented architecture (SOA) based integration environments, services created as “integration enablers” aid the integration between consumer and provider applications. Depending on the pattern of integration, such service integration enablers reside in middleware or in designated applications. In known SOA scenarios, data optionality is defined manually during the service specification phase. Data optionality is defined in a limited manner by accounting merely for the service specification phase. Defining data optionality by considering only the service specification phase drives the interface to become flavored by provider or consumer applications, which in turn results in a rigid interface. Thus, as new applications are introduced, the service component becomes unusable. An SOA based environment is hierarchical; i.e., there may be multiple layers in the hierarchy of the SOA based environment. Services in the upper layers of the hierarchy may consume services in the lower layers of the hierarchy. Defining data optionality using known manual methods is a complex task across the hierarchies. Thus, there exists a need to overcome at least one of the preceding deficiencies and limitations of the related art.